IBIS Macromodel Task Group Meeting date: 14 August 2018 Members (asterisk for those attending): ANSYS: Dan Dvorscak Curtis Clark Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki * Ming Yan * Stephen Slater Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: Randy Wolff * Justin Butterfield SiSoft: Walter Katz Todd Westerhoff * Mike LaBonte SPISim: * Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Justin Butterfield took the minutes. -------------------------------------------------------------------------------- Opens: - None ------------- Review of ARs: - Fangyi to draft a list of AMI issues that could be addressed by an AMI footprint change. - Fangyi reported he has prepared some slides on this. - Randy to investigate if/why/how a clock waveform input might be used in IBIS-AMI. - Justin reported that discussions have started, but nothing there is nothing to share yet. - Michael M. to investigate if/why/how a clock waveform input might be used in IBIS-AMI. - Michael reported that they are internally compiling and looking at a list of issues in including this. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the August 7 meeting. Mike L. moved to approve the minutes. Michael M. seconded the motion. There were no objections. -------------- New Discussion: Modeling for Memory channels: Fangyi shared slides titled "Modeling and Simulation Interface for Memory Channels". He commented that we had discussed modifying the footprint of the AMI functions in the last meeting. For the AMI Init function, the rise and fall responses needs to be addressed. The model Init function could return the Tx equalization directly. For Rx, the output could be a linear equalizer and DFE. We would not need crosstalk in the Init Tx DLL. The Rx DLL is expected to determine the Vref for the DFE slicer. Fangyi noted some questions we need to address. Vref is shared across a byte lane. He asked how can we model this or if it can it be neglected. He commented that Vref is determined by the controller and asked if we need to handle this. He noted the need to handle the common mode DC bias. This needs to be passed to the Rx, but he asked how does this work when you have a Tx EQ. There is no clear definition how the Tx EQ impacts the DC common mode, unless it is in the form of an FIR filter. We may need restrictions on the Tx output. He asked how would the Rx DFE align with the step response. He noted there were some ideas to split Init into different functions for memory. Fangyi noted for the AMI GetWave function we would need to input the clock waveform, so the DFE knows how to derive the proper clock timing. He asked if we need a different GetWave signature for DQ, DQS, and CA. Fangyi noted DQ is single-ended, while DQS is differential. He asked if we need different definitions of GetWave for DQ and DQS and if we need different stimulus for the different signal types. He commented we need to clarify the Tx GetWave and mentioned SiSoft and Cadence have proposed proprietary solutions can handle this. But, for a non-linear system you have to use certain techniques. He wondered if Tx GetWave can be eliminated and noted this would make the problem much easier. Most SERDES do not use Tx GetWave. He noted that this may not be a comprehensive list of the issues. Fangyi considered a component centric model which would handle all DQ, DQS, CA and CLK signals in a single DLL. There would be no need for a reference, and the model has all the information it needs. Vref sharing would be naturally handled inside the DLL. But, this would increase the complexity. He stated this could also force the user to simulate everything even if they are only interested in a few signals. Arpad asked if it would have to be every signal, or if it could be broken up. Fangyi replied that it could be subdivided, and this could be attractive. Ambrish asked if the AMI GetWave model needs to behave differently for rising and falling edges. Fangyi stated only the analog portion of the model will be different. Ambrish thought only the data needs to be input to the DLL. Fangyi agreed and stated that he would input two impulse responses. Ambrish asked if this can be handled in the EDA domain. Fangyi stated the EDA tool can handle this. Ambrish noted that he does use Tx GetWave, and he does not think we can eliminate Tx GetWave. Fangyi stated that we will need to address this problem then. Mike asked about the alignment for GetWave and if this is a clocking issue. Fangyi replied yes, it is. Mike thought the model would need to change to address this. Fangyi agreed and noted this would be used for the DFE timing. Fangyi asked if we want something beyond AMI and if we want to combine things into a Component Centric model. Mike thought the essentials for this are the same as they were for AMI. He asked if it is essential to have both statistical and time domain. Fangyi stated this is a good question. Arpad stated it sounds like we are thinking about something beyond AMI and asked Fangyi if he had any thoughts what this would look like. Fangyi replied that the Component Centric model was one example. Michael asked what Fangyi means by AMI framework, and how the AMI flows would need to change. He asked if we believe an AMI approach to DDR is inaccurate. Fangyi thought that it is an approximation, but it is still a useful approach. Arpad asked if we think this is possible. Ambrish stated that we are getting closer to the LTI approach, and we must think about how to handle this in the current framework. Arpad asked Ambrish how many of the changes he thinks would be necessary. Ambrish agreed about the DQS timing and Vref as necessary. He thought that these can be handled in the model or by the tool. Arpad asked if we did write a BIRD to address these if he would agree with it. Ambrish commented that we should take a minimalist approach to the changes. Arpad stated that we would try to separate the topics into different BIRDs as necessary. Ambrish thought that we could reach some agreement. Arpad asked what our next steps should be and asked if we should identify some of the most pressing issues. Stephen suggested to do a straw poll to sort the list. Fangyi thought that there are still a lot of questions. Arpad asked how many of the questions are necessary. Fangyi replied that all of the questions he listed are necessary to answer. Arpad stated he hoped to narrow down the scope of the BIRD with these slides. Stephen asked if we should do this offline. Arpad thought we could entertain a motion. Fangyi stated in his opinion it is more efficient to discuss these questions in the meeting. Ambrish commented the most important things to discuss are the ones he mentioned earlier. Arpad asked if we can decide how to approach the issues next time. - Bob: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. ------------- Next meeting: 21 August 2018 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives